The Modern .NET Show
For AI agents: a curated index of this site is available at /llms.txt, with the full version at /llms-full.txt. A clean markdown version of any page is available by appending index.md to its URL path.

S08E24 - Giving AI Agents Safe Access to Your Data: SQL MCP Server with Jerry Nixon

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

S08E24 - Giving AI Agents Safe Access to Your Data: SQL MCP Server with Jerry Nixon
The Modern .NET Show

S08E24 - Giving AI Agents Safe Access to Your Data: SQL MCP Server with Jerry Nixon

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

In this episode, Principal Product Manager Jerry Nixon makes a return visit to The Modern .NET Show — having opened season eight talking about Data API Builder, he now closes it by talking about SQL MCP Server. As Jerry explains, the two are really one and the same: SQL MCP Server is Data API Builder with mcp enabled = true, the same engine wearing a name that people were actually searching for. With Data API Builder 2.0 freshly generally available, the timing was, as Jamie puts it, serendipitous.

Jerry walks Jamie through what an MCP actually is — an HTTP endpoint with a standard request and response shape that every modern model understands — before drawing the distinction that matters most: the data plane. SQL MCP Server is deliberately not a natural-language-to-SQL tool. Letting a model write and execute its own queries is tempting because it’s simple to explain, but models aren’t deterministic; the same prompt can produce a different query every time, and a subtly wrong query returns confidently wrong data. Instead, the LLM expresses intent — the values, the predicates, the tables it cares about — and the deterministic query builder inside SQL MCP Server (written, Jerry notes, by the SQL team) constructs reliable T-SQL behind a set of guardrails.

Security and abstraction sit at the heart of the conversation. Because the server acts as an abstraction layer, the back-end data source can be SQL Server, PostgreSQL, MySQL, or Cosmos DB without the model ever needing to know. More importantly, on-behalf-of authentication means it’s the person who invoked the agent — not the agent itself — whose token appears in the database audit logs; as Jerry memorably puts it, you’d rather hold the worker accountable than give the shovel its own identity. Jamie and Jerry also dig into context-window management, and why exposing only seven built-in tools — regardless of whether a database holds ten tables or ten thousand — keeps a model from being overwhelmed into hallucination.

Looking ahead, Jerry previews the embedding capabilities coming to SQL MCP Server: a /embed endpoint in 2.1 that chunks and embeds natural-language strings for you, and semantic search in 2.2 that can run even against databases without native vector support — good news if you’re still on SQL Server 2016. Throughout, the recurring theme is the one Jerry championed last time too: simple is almost always the best solution, and SQL MCP Server is built to let you defer complexity until you genuinely need it.

Whether you’re a .NET developer wondering how to safely connect an agent to production data, an architect weighing the audit and security implications of agentic access, or simply curious about where MCP fits alongside REST and GraphQL, this conversation lays out a pragmatic, security-first approach to exposing your data to AI — using an open source, free engine you may well already have installed.

Episode Transcription

In the agentic world that makes a lot of people really uncomfortable because what ends up happening is the agent has it, the agent has its own ID and then interacts with your data database.

- Jerry Nixon

Hey everyone, and welcome back to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. I’m your host Jamie Taylor, bringing you conversations with the brightest minds in the .NET ecosystem.

Today, Jerry Nixon returned to the show to talk about SQL MCP Server, something of a new product and the evolution of Data API Builder; which we talked to Jerry about back in episode three of this season (there’ll be a link in the show notes). Jerry does a much better job of introducing it than I can, but suffice it to say that SQL MCP Server is an MCP Server which abstracts away intracting with a SQL database… of almost any flavour. SQL Server, CosmosDB, Postgres, you name it.

I mean there is nothing better for any agent than saying "new session." That is how you like create better answers all the time. You might feel like you have this session, you’ve been training it so long and you’ve told it so much, it has so much context that now when you ask it, it’ll finally have the answer that you’re looking for.

- Jerry Nixon

Along the way, Jerry shared a lot of solid gold nuggets of advice about MCP servers, best practices for interacting with agents and models, and even context management. And, of course, we talk about how simple is almost always the best solution (and how SQL MCP Server might be one of the ways for you to achieve that).

So let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : So Jerry, welcome back to the show. Wow, you were on the show right at the beginning of season eight, and you’ll also be the final episode of season eight. So you’ve bookended the season. This is awesome.

Jerry : I am the Alpha and the Omega, Jamie. This is absolutely incredible. Well, don’t let the lightning strike me — I just got the beginning and the end.

Jamie : Awesome. So we’re going to be talking about some stuff in the episode relating to SQL, to MCP, and presumably to agentic development. But I figured, in case folks didn’t catch the first episode — and you should totally go back and listen to that episode, folks, because we talked about the amazing Data API Builder — could you give folks a really quick… like we’re in an elevator and you’re going to introduce yourself to somebody. How do you do that? What’s the work that you do over at Microsoft?

Jerry : Yeah. Programmatically, you want to interact with production data. You either have a REST API or a GraphQL API against it. You write a custom one, or you use an engine like Data API Builder that does it for you in a nice, secure, feature-rich way. That’s where Data API Builder really sings, because it allows you to delete a considerable portion of your code base that’s just repetitive code you don’t really need. It gives you this robust and secure API that you can use across all of your databases and all of your applications. It’s deployed as a container, or not, depending on how you want it. That’s Data API Builder.

Probably the most important thing to say is that it’s an open source, free project from Microsoft. So you can use it on-prem, or in another cloud if you want to, pointing against any of the Microsoft SQL databases, or Postgres, or Cosmos DB.

Jamie : I really like that. We talked about it a lot in the previous episode, so folks, if you’re interested, give that a listen. But yeah, I love that it’s open source. I love that it works on all the SQLs — or at least the ones you mentioned.

Jerry : That’s right.

Jamie : Deleting code is the best way to add new features — just remove code. Removal of code means you have fewer places for bugs to appear, right?

Jerry : That’s exactly right. There’s so much opportunity for error, and yes, less really is more. If I were to say one other thing about Data API Builder: when you and I spoke about it, not that long ago, we hadn’t gotten to version 2.0. Since I’ve spoken to you, 2.0 was released as public preview, and we released general availability just yesterday, on the twenty-second. Wait, no — not yesterday, I guess it was last week. Nonetheless, 2.0 is now out, and it’s all the features that we wish we’d had before.

The previous iterations of DAB were really amazing. These new releases that we have today, they are just everything. It is such a compelling story. So when we talk about SQL MCP Server today, together, we’re going to be talking about Data API Builder too, because they are part and parcel.

Jamie : Nice. I love that. When a plan comes together… we’ve serendipitied our way into V2 of Data API Builder at the same time as SQL MCP Server. I love it.

Jerry : Yeah, well done. That’s “serendipity” — I’ve never heard of the verb version of that. Excellent use.

Jamie : I think we just made it into a verb. That’s what we just did.

Jerry : The evolution of the language, right here.

Jamie : Absolutely.

Jerry : So let’s dive into it, because this is a deep subject. It really is.

Jamie : Yeah. So I know, through my own experimentation and my own learning through the show and all sorts of things, that MCP — in this context — stands for Model Context Protocol, right? So I can do something with my agent. Maybe it’s Copilot, maybe it’s Claude, maybe it’s whatever, right? There’s a whole bunch of them. I might be using one in the cloud, I might be using one on-prem, whatever I’m using.

I can say to an LLM — and this is my understanding of it, so please correct me if I’m wrong — I can say to an LLM, “Hey, this is an MCP which exposes some tools. If I ask you questions related to, or give you tasks related to, what the tool does, go use the tool instead of grepping and sending HTTP requests and trying to connect to the database yourself, or anything like that. Use this tool. The tool knows how to do it. It will help you to achieve that solution.” Just to level set, am I on the right tracks as to what an MCP is?

Jerry : Yeah, you are totally on the right track. Let me give you an example. Maybe we could think of it as an onion — there are so many analogies here, but let’s start with an onion. At the heart of everything is an LLM. So you have this model that’s able to do this prediction analysis. On top of that, to make it run, you would have an agent. The agent would be the invocation piece that makes the LLM work.

Well, that agent doesn’t really do anything, right? It’s just a program running in memory. But that agent now needs to talk to a database. An agent doesn’t know how to talk to a database, nor does it have a database driver installed in it, or anything along those lines. If you do want it to fetch data, or update data, or do anything with any system — not just the database — you have to have some intermediary, and that’s really the MCP.

So the MCP is the one thing that all the models — all modern models — do understand. They understand that signature protocol to be able to talk to it. Just to demystify it a little here, it’s just an HTTP endpoint. It looks and acts exactly like REST. It just happens to have a response structure that is very standard, and it accepts a request structure that’s very standard. That’s the MCP protocol. It’s not a new type of protocol. It’s not a new way of communicating. It’s still HTTP, it’s still JSON, and it’s still very simplistic. It just happens to be the consensus now across all of the models, so that they understand how to do it.

So if you have an agentic solution, you want your agent to do something. If it’s going to do something, you want it to use an MCP. An MCP is very thin. It doesn’t have to be some gigantic whatever. It’s just the gateway that allows it to do whatever is on the other side. So if you wanted your agent, for example, to turn on — I don’t know — the light on your porch, you would write an MCP server that has the same signatures and same structure as the MCP standard requires, or prescribes. On the other side, you would just have the simple logic of turning a light on and off on your porch. That’s an MCP server. It’s definitely not splitting the atom.

What we’re talking about today is the SQL MCP Server — an MCP server specifically designed to interact with a database on the data plane. The reason I make that distinction of the data plane is because a database has several planes. The first plane that we all experience is the control plane. That’s where I would create the database, perhaps provision security on that database, figure out which files it might live in if it’s not on the cloud, or which cloud it lives in if it is. That’s the control plane, and this is not what we’re talking about. There’s another MCP you would use just for that, dedicated to a specific family of purposes, targeted to an agent that is used by some administrator. That’s very reasonable.

The next plane after control is the schema plane. That’s where you would be creating brand new tables, dropping columns, creating columns, altering data types, creating relationships between them, and on and on. Everything that we would call, in the SQL world, DDL — the data definition language. That’s where you create the actual objects: not the data, just the objects that are intended to hold and manipulate it.

That’s yet another plane we’re not dealing with right here. You would create your own MCP, or you would reuse one like the MSSQL extension in VS Code, that is intended for the developer loop, where I’m trying to brainstorm through what would be the right way to store this data. How could I have a table like that? Maybe you’re using an agent like Copilot built into VS Code, or you’re using Claude or Codex — it doesn’t really matter. All of those can then interact with that type of schema layer, constantly iterating on the structure of your database until you’re satisfied, or perhaps even making changes later as you start to evolve.

But then this third layer is the data plane. This is the most important, if you really think about it, because — though everything is important — this is the one that gets used, and just beaten up, forever. This is the one where all your users are interacting with your data. In the SQL world we would categorise this as DML, the data manipulation language. This is the SQL that I would write not to drop an object or create an object, but specifically just to manipulate the data. That includes reading the data as well. One extra piece is perhaps executing a stored procedure.

So as your users start to engage your agentic solution against an agent, and that agent now needs to talk to your database, that’s where we go with SQL MCP Server, exposing the data plane through the MCP protocol and specification to make sure it’s compatible with your agent. That’s where the power begins.

SQL MCP Server is unique — and I would say unique with a capital U. As developers, we naturally are drawn towards simple. There are things to remember as you’re drawn towards simple: to make sure that security isn’t the compromise, and to make sure that, long term, maintainability isn’t compromised. There are many things around that which push against simplicity.

The simple thing in an MCP server that we are drawn towards is this idea of NL to SQL, or natural language to SQL. This is where I would type in my prompt — whatever it is — and that’s the natural language. Then the query that’s being written, not executed but written, is written by the model. It writes the “select this from table, and here’s my WHERE predicate.” That gets passed to an MCP server, executed against the database, and the data is returned. That’s very appealing because of its simplicity. It’s easy to explain. It’s easy to understand. You can visualise it. But it is replete with problems.

The number one problem is that these models we interact with are incredibly powerful, but the one thing they aren’t is deterministic. That means I could ask the same model the same prompt, and it would potentially provide a different query every time. Even if those differences were subtle, the impact could actually be quite significant.

So on the one hand, you value the autonomy of an agent to accomplish tasks on behalf of the user without their involvement. But if it’s an indeterminate query every time, that lack of determinism means you now have to review the query. If you don’t review the query, then you’re really just closing your eyes and praying that the query is going to be fine. Even though you may have unit tested the production of this query against the model a hundred times, there’s still no guarantee the hundred and first time is going to be the same.

This now takes away the entire benefit of agentic solutions. Instead of being able to enjoy the autonomy of the agent accomplishing a task for you, you now have this additional double burden: one, understanding the underlying data schema sufficiently so that you can recognise whether or not the query is correct; and two, knowing the query language sufficiently so that you can see the subtleties of it, if there happens to be a mistake.

We’re not really talking about the problem of “oh my, the agent dropped my database,” or “the agent dropped my table.” That’s a concern, but something we can resolve with security. What we’re really talking about is a query that gets executed against my data, returned as a response that looks correct, and is presented to me by a model that is disproportionately confident in that data when it’s wrong.

Now I look at that data and I make decisions in my business, thinking that the data I’m using is revealing information inside my data set, when actually it is misleading me. It’s not really a question, or a category, of maliciousness. It’s not like the model’s trying to ruin your business. The model just got it wrong — and now it is ruining your business.

Jamie : Right. If I can just pause there and talk about what I’m hearing. So the SQL MCP Server allows me to have my agent, via the LLM, interact with the data plane of my data. Say, for instance, I have an internal tool that I release out to the data people — or maybe the people in my business who are very interested in gathering data and massaging it, putting it into some report. I can say, “Hey, you can use this MCP server, or you can use my app.” You don’t need to know it’s an MCP server; you can use my app that I’ve built internally. That can talk to the database.

I can say, in natural language, “Get me, for instance, the sales by category for the last quarter. Just get me those. Put it into a JSON table so I can display it on screen.” Then maybe I can export that to, say, Excel, and create a report based on what we sold in the last quarter. It will then go to the database, it will do whatever — I don’t need to know what it needs to do. My end user doesn’t need to know which queries it’s running. It’s just going to go “select star from wherever, with this WHERE clause, ordering by this, grouping by this,” shaping that data, returning it to the user. Then the LLM can go, “Cool, I’ve got all this data in whatever format” — maybe it’s a table, maybe it’s a JSON blob — and I can then massage that data, not in the way of changing the numbers, but changing the presentation of it for the user in front of me. Am I in the right ballpark?

Jerry : Yeah, you really are. But remember, though, this isn’t really an API. You wouldn’t use an MCP server with the intent of getting back the data so you can present it in a table. Instead, you’re really letting an MCP server be the access point for the agent, and the agent is simply trying to answer a question.

So let me give you an example, Jamie. You might ask, “Last quarter, which of my products sold the best?” Or which one did the worst. More importantly, you would try to come up with a question that is a little more exotic, right? Like, “Who is my most valuable customer?” That’s pretty exciting, because now you’re saying, “All right, agent, you have access to all these tables. What if you could just do whatever you wanted until you could answer this one question?” It will iterate internally and attempt to answer this question for you. That’s the value of having an LLM, right?

We’re not building screens and line-of-business applications anymore. We’re just presenting this problem to the LLM, or through an agent, and then it is processing and iterating, trying to find the answer. That’s where probably the biggest risk comes: if it is producing queries that are slightly inaccurate, the final answer is dramatically inaccurate. It’s difficult for us to have that sort of answerability — how can we go in and figure out how it figured it out?

So not having your agent — not having your model — write SQL is an important first step. There will be stages where that may be valuable, but generally speaking, on the data plane, it’s nicer not to do that, because you want to be as deterministic as possible. So your model knows it wants to find your products that are all sold on the East Coast and are under $20, let’s just say. That’s actually a very nice recipe that can be constrained down to guardrails inside your MCP API.

The way SQL MCP works is: once it provides the request, the query builder inside SQL MCP Server writes the T-SQL. That means the thinking is still going on in the LLM, but then it presents it as, “I want this value, I want this predicate, I want these things,” and then SQL MCP Server says, “All right, I understand what you’re asking for, because I’ve given you these guardrails across the entire schema, or a limited schema, depending. Now I will take it and construct the SQL for you."

Our construction of SQL is deterministic every time. And we’re very good — I mean, we’re the SQL team, we’re very good at writing SQL. So the resulting SQL is not just reliable from an “it’s always the same” point of view, but also reliable from an “it’s a good job” point of view. We still give back the answer to the LLM. We just don’t add the additional burden on the LLM to create the valid SQL.

Jamie : Right. Okay. To correct my understanding, then: previously I had said, “Hey, agent, go use the MCP server.” I think I’d referred to the agent maybe saying “select star from.” But actually, the agent is talking to the MCP server and saying, “I want this information. I don’t know how to get it. You need to get it for me. I know my user wants me to get — like you said — maybe products that are sold in this area that have a value of less than twenty dollars. I don’t know what the data plane is, I don’t know what data store it is. MCP server, you go figure it out. Go do the thing.” Now you’ve got it. Then maybe the MCP server runs a whole bunch of different SQL that I can’t see, that the agent can’t see — the MCP server isn’t exposing it. It does some stuff, returns with that data, and goes, “Here you go, LLM, this is the answer to the question you asked me.” Am I getting it there?

Jerry : That’s right. That surface layer is not just a guardrail, but also an abstraction layer that makes it possible for the back-end data source to be a Cosmos DB or a Postgres database. You don’t have to worry about changing your SQL, or the LLM needing to know the back-end data source and which version it is so that it’s all correct. We do that work. It’s just identifying each of its components — “I need to know the warehousing information, I need to know all of the inventory information, and I need to know the product details” — then we construct the various queries behind the scenes and bring those back as a unified payload.

Jamie : Right, right. Okay, so there’s some opaque box there that you all and the SQL team are creating for me. I guess it’s a little bit similar — I don’t think it’s exactly the same, I don’t think it maps one to one. But for the folks who maybe haven’t used DAB, and definitely haven’t used the SQL MCP Server — a lot of us have got experience with using Entity Framework. We can say to our in-memory DbSets, “Hey, products dot…” and then I can use LINQ. Either I can use LINQ to… is it LINQ to SQL? There are two different types of LINQ, right? There’s the dot-annotated LINQ, and there’s the “from collection where,” right? I can use that.

Jerry : Yeah, LINQ and lambda, or the methods.

Jamie : That’s it, yeah. Thank you. When I do that, somewhere behind the scenes, Entity Framework talks to a specific driver for the database that I’ve told it about, and generates the SQL. But I think the difference here — and please correct me if I’m wrong — is that I don’t need to tell the MCP server which driver to use. I maybe have to point it at the database and it figures it out. From an agent talking to the API, I guess, of the MCP server, I don’t need to go into this table, go into this collection, use this driver to generate the SQL. I, as the agent, could say to the MCP server, “I want data. I want this data, in this shape, about this thing.” Then the SQL MCP Server does whatever magic it needs to generate whatever SQL, and it will go to whichever database I need.

Like you said, it’s an abstraction, right? The database is now an abstraction. It’s like I push on the gas pedal and my car goes forward. I don’t need to think about how I push on the gas pedal and gas is injected into the engine and a spark fires and it explodes, which drives a piston, which then converts into rotary motion, which then turns the wheel — which itself is all an abstraction. But I don’t need to think at that level, right?

Jerry : That is an excellent explanation of it, actually, because the intent is to make it so that we don’t dilute the context of the model with extra information that it really shouldn’t have anyway. It is an incredible benefit from a security point of view, but that’s not really the driver. The driver is: how can we make these models more successful in interacting with the data, while protecting the data?

So remember, I could write an MCP server at any time that allows the model to write the query and just pass it through and execute it in SQL. The problem is the database itself. We need to think about a production database as the most valuable asset of any company. So we want to reduce the surface area, and the risk against that, making it so that all the things that can happen inside that database are limited to, or constrained down to, a simple set of operations.

One of the ways we can limit it is through security. In a typical line-of-business application, the security model might be like this. I log into my application using — let’s just go with an Entra ID. That then has my token, but it has its own application ID inside my tenant, and it logs into the API, which has its own tenant registry, which logs into my database, which also has a tenant registry. Each one, along the way, validates the caller before it goes through the chain.

That’s just the table-stakes, bread-and-butter for everybody who’s building an application today. That’s the way APIs are written, and that’s the way security is ninety percent of the time, if not more. In the agentic world, that makes a lot of people really uncomfortable, because what ends up happening is the agent has its own ID and then interacts with your database. Even though that technically does work and is fully functional, it is a little awkward, because when you’re looking at the audit trail of who did what, you’re now at the point where it’s almost like digging a hole and the shovel has its own identity.

I’d rather know the worker who has the shovel. That’s the person who cut the line, that’s the person who dug too deep, that’s the person who did whatever. So on-behalf-of authentication — which is very rare to implement in an API scenario — is what we really are striving towards in an MCP scenario. That’s because now the one operating against the database is the one who invoked the model in the first place.

So if it’s me talking to an agent, the agent talks to an MCP, the MCP talks to the database — it is still me and my token that’s in the audit logs of the database. That’s particularly appealing when you think about it from a security point of view. It’s one of those things where you’re like, “Well, how are you going to build your MCP? Okay, but how are you going to abstract all the data? Now, how are you going to do authentication? And then how are you going to do authorisation behind the scenes? Are you going to have RBAC at the API level? Are you going to have RBAC at the database only? Is it going to be all through the solution?” It’s fascinating, really, how many questions there are to answer.

That’s, again, one of the primary reasons we built SQL MCP Server: because it deals with all of these things for you. You just configure that JSON file, and we do it from there. You pointed out how similar this is to Data API Builder — because this is Data API Builder behind the scenes. Data API Builder has a REST endpoint, a GraphQL endpoint, and an MCP endpoint, which means one JSON configuration file against your database can provide all three solutions, or each individually, however you want to set up your topology.

Jamie : Wow, that’s really cool. Especially for folks who haven’t used Data API Builder. One of the things I’m talking about a lot on the show this year, Jerry, is that I’m realising that I, as someone who speaks to folks like you, am at the forefront, whereas perhaps most day-to-day — especially enterprise-level — .NET devs don’t get much of a chance to try out new things. They hear about something on a show like this, or they go to a conference, and they go, “My goodness, that would be awesome.” Then they go back to work and they’re like, “Right, okay, so I’m building my forms-over-data app and I’m using Entity Framework” — whichever version fits, whichever version works with the version of the SDK that I’m constrained to, because I may not have the time to upgrade.

For those folks who haven’t used Data API Builder, it is literally that. Jerry and I spoke about it on the previous episode, but it is a case of: you create a JSON file which represents all of the things to do with connecting to your database, and then Data API Builder just figures out an API for you. It is fantastic.

Jerry : Yeah. I mean, I love Entity Framework, and I totally understand why it’s so appealing to developers, because it eliminates — really, it eliminates — the need to know T-SQL, the need to really understand how to build structures inside of SQL. It does it for you with the migrations. So I totally get that.

However, there’s going to be this crossroads, we’ll say, where the size of your database is so significant, where the scale of data is so significant, where the complexity of your objects is so significant, or frankly where the maintainability of your application is so significant, that you’re like, “Hmm, I feel a little discomfort in my Entity Framework solution.” That’s because it’s pushing up against the boundary that it has. Can it be done? It can always be done — we are engineers. With enough time and money, we can get it done, we can make it work. But is it the right solution?

So you’re absolutely right. Data API Builder steps into the gap and says, “Nine times out of ten, all you’re really doing is CRUD operations against your database. Let us do that for you.” But we also recognise that one time out of ten you have to do something special, whatever that might be. Maybe Entity Framework comes back into the picture — that’s totally fine. A mixed solution like that isn’t wrong, because you’ve still isolated so much of your code, especially the CRUD code, away to this dynamic engine in Data API Builder.

Then, once you have Data API Builder in your solution, your boss comes to you and says, “This needs to be agentic. Everybody’s talking about AI, and our investors just asked about it, and we need a story.” It turns out all you have to say is “mcp enabled equals true” in Data API Builder, and it transforms into SQL MCP Server.

So Data API Builder really does have two names, right? There’s Data API Builder, and there’s SQL MCP Server — two names for the exact same engine. There’s no difference. I mean, if you disable MCP in SQL MCP Server, I suppose that’s the difference, but in all reality… Nobody was Googling “Data API Builder with MCP capabilities.” Everybody was Googling “SQL MCP Server."

So we take this moniker of SQL MCP Server and drop it on Data API Builder, but it really is the same thing, just depending on how you approach it. The nice thing is — I was describing how you could have a REST API against your database that’s nice and robust, and you just enable MCP, and now you can have both. But you could go the other way as well. You could start from an agentic side, doing everything with SQL MCP Server, and then you’re like, “Oh, I would like to have this tiny little admin app that did this thing and this thing.” Now I can enable REST or GraphQL as well with that same endpoint. I don’t have to introduce a new piece of architecture. I don’t have to spin up anything else. Everything is right there.

Because it’s open source and free, there’s no licence — well, MIT licence, but there’s no significant licence to consider. I can move this on-prem if I need to. I can have it in AWS if I need to as well. So it’s just nice, right? Because it’s like, “Oh, now we have an MCP server. Where do I install that?” And, surprise, you’ve already got it installed. So it’s very appealing to have so many solutions in a single engine that was already pretty nice to use.

For your listeners who maybe didn’t hear that first episode, just as a reminder: this is the engine inside Microsoft Fabric that exposes the GraphQL API endpoint there. So from a perspective of secure, robust, and scalable, that’s proven, just because of that. We’re glad to give it away, because it reduces the friction of any developer trying to interact with the database.

So if you’re drawn towards Entity Framework because it removes the intensity of writing all of these queries — that’s the value of SQL MCP Server, or Data API Builder, because it also does the same thing, making it so your engineers, or your application, interact with the database just over HTTP and JSON. It’s nice to have… the same story that we have for APIs and line-of-business apps is the exact same story we have now for agentic applications as well.

So we get to reuse that robust query engine that we have inside Data API Builder. When we say things like pass-through authentication, or on-behalf-of authentication, that’s really important for agents. As soon as we enable it for agents, you also get it on the API side as well, for REST or GraphQL. So it’s really cool to be able to build into this, and every time we add a feature, it’s across all of the use cases.

Jamie : I love that, because it’s something you hinted at earlier on, when you said that, as developers, we love the idea of a simple solution, right? We’re drawn to simplicity. There was something you said last time you were on the show, all those months ago, about how simple is always the best solution, right? A simple design is always the best solution, because it’s easier to think about, easier to reason about, easier to secure.

Especially to your point earlier on: if I am using an agent with an on-behalf-of token, or some on-behalf-of identification, authentication, authorisation, then, like you said, it can be traced back to me. So if you do end up with a malicious user, or someone doing something a bit silly, you can figure out who it was that did it. But if you have just an agent working directly against the database, maybe writing its own SQL…

Jerry : It’s a mystery.

Jamie : Yeah, right. It maybe then needs to create a little Python app to talk to the database on your behalf. You don’t know who gave the LLM that instruction — or rather, you don’t know who caused that SQL to run, because there’s no connection there. So yeah, I love that idea of being able to trace things back — not necessarily for a malicious reason, like, “Hey, you’re using a billion tokens and you’re causing bottlenecks in the database,” but more a case of, “Somebody dropped the production server, and we need to know who did it.”

Jerry : Right, yeah, that’s exactly right. Authentication is so important. What’s nice is, when you choose a robust engine like this, you don’t have to think about authentication until it’s time. Then, when you’re there, you don’t have to back out of all these compromises — you just enable it. So that part is nice as well. It should help you sleep at night, knowing that you’re going to use an engine where, when we get around to figuring out how complex the authentication needs to be, it probably already supports it. So I think that’s an important place to be.

By the way, last week I was in an architectural session with a bank — a customer of Microsoft, a really large bank that would be easy to know by name. When they get to the point where they’re like, “All right, who do we give authorisation to inside the database?” — well, option number one, you authorise the agent to do something. That was the showstopper. They’re like, “We’re never authorising an agent, because that’s like giving authority to the hammer, giving authority to the shovel. We’re going to give authority to the people, and then they can go through it."

It’s really nice, because when you start talking to people whose entire job is to safeguard the integrity of the data of your business, they suddenly start caring about things, and they’re like, “We’re not really interested in whether or not it’s easier to engineer this. We’re talking about the security solution, and it’s going to go this way.” It’s interesting to me how that can really be the trump card that’s played. It’s like, “Oh, okay, well, we thought we were going to use Entity Framework and we were going to do it the easy way,” and they’re like, “Great — rewrite everything."

So it’s just nice to be at a place where it’s like changing the channel on a TV. “Which authentication model should we use?” You just switch to the one… eventually you get to a point where, whoever the guardian of your production data is, they’ll have these requirements. I was on another architectural call with a state department in Scandinavia, and they were approaching it from a different point of view. They had data that was available — publicly facing data. But the only way they could expose it to anybody on the outside was to give database logins to the users and then show them how to have touch points into that. Basically, launching SSMS from a customer’s perspective and then connecting into SQL Server. They would have security, but it was a terrible thing to manage. You could just see how clunky and terrible that is, and what an awful experience it would be for the customer.

So they saw it another way. They said, “Let’s take our data and translate it into being a clearinghouse.” So instead of building an application that has an API endpoint, they built an API endpoint without an application. It dramatically improved the scenarios for all of their customers, who have no problem talking to an API surface. They weren’t looking forward to using SSMS, or anything like it, anyway.

Then they’re like, “Oh yeah, now there’s a new initiative inside the entire government to have these agentic protocols.” It turns out you can say “MCP enabled equals true,” and the same thing that you built six months ago is now an AI solution as well, without having to introduce all the caveats that usually come along with it — raw access, weird security, and all of these things. So it’s really cool.

I’ve had a tremendous opportunity to talk to different customers and the way they’re using it. I would say the most practical sense is: I want to build fewer screens inside my application. I want to instead ask my agent to do things for me. As it does things for me, it just needs the CRUD operations against the database. That’s the nice step number one.

Step number two, though, would be information discovery. Information discovery is amazing. It is perhaps the pinnacle of the way we’ll use agents in the future. It’s basically where we say to the agent, “We don’t really know what we have here, but I think you could find our next big opportunity. Just go to town.” This is a long-running request that you would prompt an agent to do. It would — not to say beat up your database — but it would run many queries, trying to find patterns and trends that you maybe didn’t anticipate.

This idea of information discovery is really beautiful, because it can come back with an answer to a question you didn’t even know you were asking. You want to be able to provide access to that as well. You don’t want to just say, “Here’s the very simple, nickel-and-dime, ABC CRUD operations.” You also want to have this broad-reaching, expansive access to the database — where, on the back end, you’ve probably created a read-only replica and you’ve made sure you’re not going to impact production activities. But you also want to have an agent just go, go, go, and research, research, research. Both of those are scenarios that we intentionally built for with SQL MCP Server.

So we have a handful of tools. A normal context window of an LLM is limited to a certain number of tokens. That token window is actually much smaller than people realise. Even though you might see a window of a million tokens, there is no LLM that has a million-token window, because the input and output by themselves share that limit. So now you have this input limit of a certain number of tokens.

If you provide too little, it’s naive and can’t really do operations. If you provide too much, then it’s overwhelmed and probably diluted, so it’s not able to make good decisions either. So you want to stay in this middle ground. One of the most important ways to stay in this middle ground is to make sure that the tools you provide to it don’t overwhelm it with too much information.

What I mean by that is I could provide an MCP server of any kind with 100 tools. By the time I got to 100 tools — because every tool will have semantic descriptions, every tool’s parameters will have semantic descriptions, and every tool’s result types will also have semantic descriptions. That’s really important, to make sure the model understands what it’s about to do and how to use the data that’s going in and coming out. Say I have ten tools — that’s a lot of information. I have a hundred tools — now that’s really serious.

So create, read, update, delete is four operations against the table. I have ten tables — that’s potentially forty tools. I have 100 tables — that’s 400 tools. It’s a guarantee that I’m about to overwhelm the context of these models, and their ability to process reasonable answers to our prompts dramatically falls off the cliff.

So the way SQL MCP Server does it is we provide built-in tools — and we provide seven. Seven built-in tools that make it so we can have all of this robust interaction without constantly growing. What’s nice about that is, if you have a database with 10 tables, you have seven tools that you’ll provide to a model — very manageable. If you have a database with 1,000 tables, you have an MCP server with seven tools that you provide to a model — still very manageable.

So we have this scalability answer as well, to make sure that if you have an incredibly robust database that has all kinds of objects in it, you still have the opportunity to provide that back to these models without blowing their context out of the water. There are so many little things to think about that we’ve had to incorporate into SQL MCP Server to make it the right answer for small student developers who are just trying to get started, startups who maybe have a small, modest database, or these enormous enterprise customers that you can’t believe are customers of Microsoft. SQL MCP Server is quite the answer across the entire spectrum of customers.

Jamie : I really appreciate you talking about the token context window there, and not overwhelming the underlying model. I’m currently reading through a book called Agentic Design Patterns. It’s from earlier this year, so it does talk about prompt engineering, but it talks about this idea that you don’t want to give a model too big a set of things to do all at once. So, instead of saying as one prompt, “Look through the data and build me a report about the thing,” you might say, “Go get some data and summarise that.” Cool, I’ve done that, here’s the summary. “Great. Now that you still have that data around, look for trends about X, Y, and Z.” Okay, it goes and does that. “Cool. Okay, now build me a report.” Maybe you’re forwarding those prompts, and the data, to slightly different models — one that’s maybe better at writing prose, one that’s maybe better at visualising data, right? Splitting those into smaller steps.

If you are able to expose everything required to interact with the database — at an abstracted level, regardless of the number of tables — through only seven tools, then there’s absolutely no way, from the tool-count point of view, that you can overload or confuse an LLM, cause hallucinations, and cause it to lose track of where it is, and things like that. Because there are only seven tools, right?

If I sit you down and give you a toolbox with a hammer, a wrench, a saw, and maybe a plane — or whatever you call it, for shaving off bits of wood — and I say to you, “Build me a handle,” you’re only going to use those four tools. But if I give you a toolbox with a thousand tools in it, of all sorts of different kinds — a different kind of file, four different hammers, twelve different saws — you’re going to have trouble figuring out which tool to use to create the handle that I’ve just told you to make.

So absolutely, I fundamentally, 1000% agree on the reduction of tools exposed by an MCP. I’ve worked with teams in the not-too-distant past where someone will get — I’m fearful of the phrase, but — “MCP joy.” “Oh, there’s an MCP for this, I’ll install that. Oh, there’s an MCP for this, I’ll install that. I’m never going to use them, but I’ll install them anyway.” Then they’ll fire up a new instance of their model, their agent, whatever, start a new session, and they realise they’ve overloaded the system context immediately.

They’re complaining, “Why? What’s going on?” Well, how many of these MCP servers that you’re not using have you got installed? They haven’t understood that, when you have them installed, it has to tell the model, “Hey, I have these tools, these are my descriptions for these tools, and here’s how you can call these tools” — regardless of whether it’s going to use them or not.

So I absolutely agree that the fewer tools you can have, the better — because it’s the simple solution. Why don’t we keep going back to it? Keep it simple. Make it simple, and no simpler. Right.

Jerry : Yeah, and Jamie, you made a good point, because the hallucination problem is really a result of either too little in the context, so that it’s naive, or too much in the context, so that it’s over-diluted. It doesn’t have the ability to find the signals to give you your answer.

Then it has this weird characteristic where it’s going to give you an answer no matter what. So: I know so little, but you ask me a question, and I’m just going to guess at the answer. Or, you ask me a question, but I know so much that I don’t have time to go through it all, so I’m just going to take the top couple that I find.

As a result, the response from these LLMs — we call it hallucination, but it’s really the best effort given the terrible amount of context that it has. So if you can provide it fewer tools, if you can provide it fewer prompts… I mean, there is nothing better for any agent than saying “new session.” That is how you create better answers all the time.

You might feel like you have this session, you’ve been training it so long and you’ve told it so much, it has so much context, that now when you ask it, it’ll finally have the answer you’re looking for. But the reality is, if you’ve gone that far, it has no choice but to go through compaction. It doesn’t go through compression. Compression is where you take all the data, compress it into something small, but then explode it later and decompress it. That’s not what it does, because there’s still a token limit inside the context window.

The only thing it can do — compression being out of the question — is compaction, which is summarisation. So imagine you and I are reading to each other, and you’re reading me the cure for cancer, and let’s say it’s 10,000 lines of formula. We get to 9,000 of those lines, and I’m like, “Hang on just a second, I need to do compaction.” I take the cure for cancer that you’ve been reading in the last 9,000 lines, and I summarise it. It’s absolutely destroyed.

Once we understand the mind space of these LLMs, and we stop pretending like they’re God, then all of a sudden we’re like, “Oh, we can really use these effectively, and in a reliable way.” So you’re right — that’s the reason we minimise the number of tools inside SQL MCP Server.

However, if you do have 10,000 tables, or 20,000 tables — we have customers with hundreds, we have customers with 5,000 schemas, and then the tables come next. It is crazy what customers will do. They’re always the ones who write the biggest cheques, so we have to say, “Yes, sir.” It’s just one of those things where we’re like, “Yep, now we could support 5,000 schemas.” Actually, we could support more than that.

Well, if you do have that size of database, the reality is the information needs to be provided somehow back to the model so that it can do it. Hopefully you’ve done that first step of narrowing down the access, so that you don’t provide everything anyway. But then, one of the tools we provide is an access tool into the schema itself. So they can start to ask questions for specific tables, groups of tables, and things like that, that you’ve provided through our abstraction layer.

Then we page that to it, so it’s nice and slow. We don’t just say, “Here’s all billion of them.” From those, it can explode them out, say, “Oh, the customer table, that’s the one I was looking for. Tell me all the columns, describe every column in detail.” Now it can grow the information it needs, but it can do it slowly but surely, with only the objects inside the database that are relevant.

I would say, since GPT-4.1-mini, the agentic workflow has been pretty successful. I have a lot of customers who are doing internal solutions that don’t have access to OpenAI, or to Microsoft Foundry, to use models, and they are running Ollama, and they are still having success with this workflow — to say, “Oh, with only seven tools, I need two hops instead of one.” The first hop is to describe the structure. The second is to do the read — or the second is to do the update. That’s totally fine. There was a time when agents really struggled with this workflow; they needed one thing and they would lose track. But that’s really not true anymore. The sophisticated flow is second nature. It can do it on the back of its hand. It’s not that big a deal.

So that’s been a great success story for us as well — to know that we can leverage the internal capabilities of these models, and we’re providing tools that are built in. It just knows exactly what to do. We, of course, provide semantic information with SQL MCP Server out of the box, so that when a model connects to it, or when an agent connects to it, the first thing it does is list the tools, and we provide very detailed guidance back to the model to say, “This is SQL MCP Server. On the back end is a database. Here’s how you use our tools."

That has proven to be exactly the recipe needed for success. It has been a real roller-coaster ride of excitement to watch customers enable this, cross their fingers, close their eyes, and push go. It still works. They don’t have to do all of these extra instructions to make sure their agents can follow a workflow. They just work out of the box, in part because of the semantic data that we provide, and because of the internal capabilities of these models.

Jamie : So you’re saying we don’t have to do Hail Mary driven development, right?

Jerry : Hail Mary — that’s exactly right. Squint and click. Brilliant. It’s a big deal.

One other thing I think is worth talking about before we wrap up here is the idea of embedding. Embeddings are different, right? Embeddings are the ability to find semantic similarity between two natural phrases. For example, you could search “dog” and find “puppy.” That’s really valuable. The way you would do that is you would take a sentence — you wouldn’t take a paragraph, you would take a sentence — and then you would embed that into a vector. Of course, SQL Server can take vectors now and just store them natively. A vector is just an array of floats.

It’s really important to recognise that you wouldn’t take a paragraph and embed it, because that vector might be an array with a dimension size of 300 — let’s just make it big, a thousand, maybe. That’s because now I can take it and provide it to an embedding model. Now, that’s not the same as an LLM — this is the embedding model.

So the embedding model takes my sentence. It sees, “This is a game that’s fun on vacation,” and that’s the sentence. It’s like, “Oh, okay, I can embed that.” Now I can search for things like “winter break” and “vacation” still shows up. I can say “game,” and I can say “entertain kids,” and it still shows up. So it’s really nice to have that semantic thing. All of that information then gets jammed into that one array.

That’s the reason that if I had two sentences and I was trying to embed those, if I tried to put them both into that one array — well, the data has to go somewhere, and there are only so many dimensions. So now I’m like, “Oh, okay, two sentences jammed into one array” — now I’m starting to lose information. An entire paragraph of five or six sentences, all jammed into one array — now I’m really starting to lose information, because I’ve had to summarise the entire paragraph and then embed that summary, instead of the paragraph itself.

That could really be a bummer when you’re looking for something specific inside your relationships. So the solution, of course, is chunking. Chunking takes a long natural string and breaks it into predefined sizes, then embeds each of those predefined sizes, while still remaining related to each other.

The reason I’m bringing this up is that another feature of SQL MCP Server we haven’t really touched on is internal embedding. Right now we just went GA with 2.0, and 2.1 is right around the corner. 2.1 will have the ability — just like you can say “slash API” and get to all the REST APIs, “slash GraphQL” and get to all the GraphQL APIs, “slash MCP” and get to all the MCP tools — now you’ll be able to say “slash embed.” It will take a natural string from you, and first of all it will chunk it for you — based on a strategy that you provide, or our default strategy — and then we’ll embed that for you as well, returning an array of arrays, right? Because you might have to chunk each one, each representing a chunk, of all those vectors, that you can then insert into your database, or use in some application where you have to be able to do the mathematical similarity between those arrays.

Because when people say “semantic similarity between two strings,” they don’t mean it literally. What they mean is the mathematical similarity between two arrays. We can do that without a model — we can just run a cosine distance, and all of a sudden we can start to figure out what’s closest.

What’s beautiful about that is that the embedding process is actually a complex process, and we’re trying to simplify it by making it just an internal subsystem of SQL MCP Server. So I have this string, I’d really like to be able to embed it — now I have to build an embedding pipeline. Whoa, whoa, whoa. Maybe. Or you just take SQL MCP Server and embed it that way.

Then, for the next feature — not to talk too far into the future, but the future of SQL MCP Server — this is one of the few times, Jamie, that I feel like Microsoft is three steps ahead of our customers, instead of three steps behind. So instead of running to catch up, we’re where they’re going to be tomorrow, rather than where they are today. So one of the next things will be: would it be possible for me to pass in a natural language string, and then find the record that matches that inside my database? Well, that’s very complex. SQL Server has a solution, Postgres has a solution, Cosmos DB has a solution. But I’d like to centralise it and simplify it, so that I can just do it at the API layer.

We’re still going to use the same embedding model that your corporation already uses today. We just hide all the complexity. So where 2.1 is going to have an internal embedding system, 2.2 — we actually call it phase four — has this next thing where we’ll be able to do a semantic search against a table, even against a table in a database that doesn’t have semantic search capabilities. This isn’t really relevant to SQL Server 2025, because it’s all built in there. But not everybody gets to use that — like you were saying, you’re constrained by whatever your company has. So if you’re back on, you’re like, “Oh, we’re still on 2016.” Great, now we have semantic search against the 2016 SQL database.

So when you start seeing the future vision of how we’re continuing to evolve this… By the way, it’s not like we’re adding a licence and a fee to this — it’s still open source and free. So, very, very exciting. Because you are the one who determines how to host it, you are the one who gets to determine where it’s going to live and how much it’s going to cost. It’s great that we give you all of that capability as well. So what do you think of that, Jamie? Neat, right — around the embedding scenarios?

Jamie : Yeah, that is genuinely really cool.

You know that moment when a technical concept finally clicks? That's what we're all about here at The Modern .NET Show.

We can stay independent thanks to listeners like you. If you've learned something valuable from the show, please consider joining our Patreon or BuyMeACoffee. You'll find links in the show notes.

We're a listener supported and (at times) ad supported production. So every bit of support that you can give makes a difference.

Thank you.

Jamie : Just real quick, to check my understanding of what you’re talking about there, with a fake example. Let’s say I’m a Walmart-like, CVS-like, Target-like, Trader Joe’s-like, Amazon-like system, right? I’ve got a million products. I sell them all in retail stores.

Jerry : I love that you used Amazon as an example, by the way. Amazon is Azure’s largest customer. A lot of people don’t know AWS is hosted on Azure.

Jamie : Oh, that’s really interesting. Okay, right.

Jerry : No, Jamie, I’m joking. I’m joking.

Jamie : I know, I know. I just wanted to go with it, see if… The problem is that somebody’s going to listen to that and take it as serious, and then—

Jerry : That’s the soundbite they’ll keep.

Jamie : Yeah, yeah. But let’s say I’m some kind of physical store — retail, supermarket chain, right? I’m a CVS-style, Trader Joe’s-style — the kind of store where you can walk in and buy all of your groceries, over-the-counter medication, frozen goods. Maybe the kind of place where you can also buy sporting goods and things like that, like a Walmart, or something similar, right? I’m one of those. I want to be able to search for all products that are rated as maybe diabetic-friendly, right? Whatever — like melatonin pills, pain medication, snacks, groceries, all that stuff.

If I have something that can take semantic meaning from the descriptions of the products using embeddings, and if I use the embeddings and chunking and stuff like that, that will allow me to do that, I can then say to my agent — which has access to the SQL MCP Server — “Find me all of the products within a certain price range that are not going to hurt me, because I am a person with type 2 diabetes, and I’m interested in snacks. I’m interested in this, that, or the other."

Then it will go, “Cool, okay, right.” It talks to the MCP server, the server goes, “Right, I will go figure all of that out,” and then it returns a list of products, right? Maybe it’s mid-afternoon and I want a snack. This is a really niche, specific example — I’m hoping nobody needs to build this, but it’s niche. Middle of the afternoon, I want a snack, and maybe I have type 2 diabetes. I can say to the MCP server, or to my LLM, “Go look at my database of products, find me the thing that I can eat this afternoon that isn’t going to cause me any problems.” Then it will use those semantic embeddings to find the products that match that thing, right?

Jerry : Yeah. Maybe a more exciting example might be, “I want something that’s healthy and won’t melt in my car in the heat.” Right? That’s an incredible way of saying it. You’re like, “What?” All of those things can be drawn out. Now, if you don’t have robust descriptions on your products, that’s going to be difficult to have semantic success in that search. But if you have very robust descriptions, and they’re provided through some sort of vector embedding, then you have all kinds of cool options. Everything that you said, you could do — absolutely.

A little bit like data projects — how they say 90% of data projects fail. Part of the reason is that getting your data prepped and ready is so difficult; that’s the reason. Semantic success is also part of a data project. You want to make sure you have your data prepped and ready, so that when you do the embedding, it’s excellent.

Because if you go to one of your examples that might have hundreds of thousands, perhaps even millions, of products — depending on how they do their SKUs — then the embedding time and potential compute cost is pretty high. Then you’re like, “Oh, I could make these twice as robust and have a better search result,” where now you have to re-embed all of those, if you’re going to do it properly. So that’s the “which one comes first?” Do you want to test this out on your entire dataset, or do you want to fix your dataset first and then try it out? What you came up with is a very nice use case that I imagine is very realistic, and it’s extremely successful when, first, the data is robust, then embedded, and then you can do these searches.

By the way, the search relationships between all of the different chunks — remember, it’s not just against the products, but against the multiple of how many chunks there are in each description as well. That relationship is incredibly compute-expensive. The reason I say that is: I want to be able to find the relationship, and I’ll pass in “diabetes,” let’s say, but I’m not really looking for things that are for diabetics. I’m just looking for things that are related to sugar content, and stuff like that.

If I have a hundred thousand products, and each has, let’s just say, ten chunks, now I have a million, and each has its own relationship to the rest of the 999,999 objects. That graph is extremely expensive to compute, if that’s the search I’m going to do, and I now have to compute a million of those.

So the way SQL Server does it — and again, now we’re outside of SQL MCP Server — the way SQL Server does it is it pre-computes the relationships, a relationship graph across all of those vectors, and then stores it on disk. It’s intense, right? This is a process that Microsoft Research invented several years ago, and now we’ve implemented it. It’s the only way to do it. If you’re going to try to do a semantic relationship between two vectors, not a big deal. If you’re going to try to do a semantic relationship between one and a million other vectors — incredibly, not only does it melt all of your servers, but your users are frustrated by waiting an hour for the answer. So that’s the reason you have to start looking at all these additional… Humanity is amazing right now.

Jamie : It is. It is. Jerry, thank you for being with us today. I feel like my knowledge of AI, MCP, and SQL has just exploded. Every time we speak, I feel like I walk away with a whole syllabus’s worth of new information. So thank you for that. I really appreciate it.

Jerry : There’s a lot here, and to be honest, there’s so much we haven’t covered yet as well. Data API Builder, and/or SQL MCP Server — we’re just a big product with a lot of things, and yet somehow it’s still small, and it’s this easy thing to add to a solution. If I were one of your listeners and I wanted to get some information and maybe be able to discover it myself, I would potentially start with our docs. aka.ms/dab/docs takes you directly to the docs. That’ll take you to the MCP docs, the REST docs, and the GraphQL docs. Everything is in one place, as well as authentication.

That being said, aka.ms/dab — without the docs — takes you to the open source repository. This is on GitHub, where everything is in the open. We’re building this. The roadmap is in the open. Our issues list is in the open. Everything is in the open. Perhaps most interesting is our roadmap. You can go into the discussions area of that repository and see not just our backlog, but exactly what we’re planning in the next handful of versions and releases of Data API Builder. That’s pretty exciting too.

There are many different videos and walkthrough tutorials that you can find on YouTube, or just by Googling, as well. A lot of them are directly accessible inside the docs also. But if you’re wondering where to get started, that’s probably the easiest way. It’s an exciting place to go.

If there was a word of encouragement I would give to you and to all of your listeners, it would be: remember that all of us are figuring this out right now. It may seem as if everybody’s talking about AI, but everybody is talking about AI at the kindergarten level right now. So this is the right time to get involved, the right time to start engaging, the right time to listen in. When you think about the HTML spec — you and I had the luxury of being part of it as it was growing. This is the AI spec. We are at this luxurious time where everything’s slowly getting figured out, and we can absorb it as it’s happening, rather than trying to swallow the entire apple later.

So this is a neat place to be, a neat time to be. It’s pretty handy to be able to use a database like SQL Server to do a lot of these capabilities. It is extremely handy to use SQL MCP Server, which isn’t tied only to SQL Server, but also Postgres, MySQL, and Cosmos DB as well. Depending on what your internal requirements are, it’s a neat option to have in your toolbox.

Jamie : Yeah, it really is. I’m looking forward to getting a play with it myself. I’ve got a few days where I don’t have any pressing work required, so I’m going to maybe see if I can create a database with loads of data in it. Or maybe just grab — is it the SolarWinds [AdventureWorks]? Are those databases still around somewhere, or something like that? Just grab an open source database with lots of data in it, throw SQL MCP Server at it, and see what I can request and see how it works, right? Maybe that’s a good way to start — find an open source database somewhere that you can poke at with it and see what happens.

Jerry : Absolutely right. That’s a terrific way to get started. Here’s a little treat you can give to your users. aka.ms/dab is the URL I told you before. aka.ms/dab/meet allows you to schedule a meeting with me. So if your manager has a lot of questions, or your lead dev has a lot of questions, or something like that, I’d be glad to talk to you, or to your listeners as well, in a short meeting, or whatever is necessary to give you the confidence to make an architectural decision.

Jamie : That’s awesome. Thank you very much for that, Jerry. I really appreciate that, and everything we’ve talked about today. I appreciate your continued patience with me whilst I ask the potentially really silly questions and fumble my way through thinking of examples and things like that.

Jerry : It’s been a delight, Jamie. Thanks for having me on again.

Jamie : Thank you very much, Jerry. Always a delight to speak to you.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest for graciously sharing their time, expertise, and knowledge.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice—head over to dotnetcore.show/review for ways to do that—reach out via our contact page, or join our discord server at dotnetcore.show/discord—all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places