Yeah, you are totally on the right track. Let me give you an example of maybe we could kind of think of it as an onion. It's really, there's so many analogies here, but if we start with an onion, you know, at the heart of everything is an LLM. So you have this model that's able to do this prediction analysis. And on top of that, to make it run, you would have an agent. And 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 needs to now talk to a database. Well, 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 at all. If you do want it to fetch data or update data or do anything with any system, not just a database, you have to have some sort of intermediary. And that's really the MCP. So 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. And 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 accepts in 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 and 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. And so if you have an agentic solution, then you want your agent to do something. If it's going to do something, you want it to use an MCP. And 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 MCP standard requires or prescribes. And then 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. And what we're talking about today is the SQL MCP server. So an MCP server specifically designed to interact with a database on the data plane. And 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. So that's where I would create the database, provision perhaps 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 is another MCP you would use just for that, dedicated for a specific family of purposes that would be targeted to an agent that is used by some sort of administrator. That's very reasonable. Then the next plane after control then is the schema plane. That is where you would be creating brand new tables. You would be 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, right? That's the description language, the data description language. Which is where you create the actual objects, not the data, just the objects that are intended to hold and manipulate them. And so, that plane, yet another plane that 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? And 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 then can 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 perhaps the most important if you really think about it, because though everything is important, this is the one that gets used and just beat up forever. This is the one where all your users are interacting with your data. And in the SQL world, we would categorize this as DML, the data manipulation language. And so, this is the SQL that I would write not to drop an object or create an object, but this is the SQL I would write specifically just to manipulate the data. That includes reading the data as well. And one extra piece is perhaps executing a stored procedure. So, as your users start to engage your agenic solution against an agent, and that agent needs to now talk to your database, that's where we go with SQL MCP server, exposing the data plane through the MCP's protocol and specification to make sure that it's compatible with your agent. And that's where the power begins. And SQL MCP Server is unique. And I would say unique with a capital U, because we as developers, we naturally are drawn towards simple. And there are things to remember as you're drawn towards simple to make sure that security isn't the compromise and to make sure long-term maintainability isn't compromised. And there are many things around that that 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, that's the natural language. And then the query that's being written, not executed, but written, is written by the model. It writes the, you know, select this from table, and here's my why where predicate. That gets passed to an MCP server, executed then it's the database, and the data 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 visualize it, but it is replete with problems. And the number one problem is these models that 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 provide potentially a different query, or yeah, a different query every time. And 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 be able 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. And 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. Because even though you may have unit tested the production of this query against the model 100 times, there still is no guarantee the 101st time is going to be the same. But this now takes away the entire benefit of agentic solutions, making it so that instead of being able to enjoy the autonomy of the agent accomplishing a task for you, you now have this additional double burden of one, understanding the underlying data schema sufficiently so that you can recognize 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. And we're not really talking about the problem of, oh, the agent dropped my database. Oh, the agent dropped my table. That's a concern, but something we can resolve really with security. What we're really talking about is a query that gets executed against my data, returned back 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. And now I look at that data and I make decisions in my business thinking that this data that I am using is revealing information inside of my data set when actually it is misleading me. It's not really a question or a category of maliciousness. You know, it's not like the model is trying to ruin your business. The model just got it wrong and now it is ruining your business.