From SQL Generation to Tool Selection: A Domain-Oriented Pattern for MCP Servers
This paper introduces the Domain-Oriented Tooling Pattern and its open-source implementation, MCP Blueprint, which replaces generic SQL generation with domain-specific tool selection to significantly improve accuracy and reduce costs for smaller LLMs in enterprise data access scenarios.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine a world where computers can read and understand human language, allowing people to ask complex questions about vast libraries of data without needing to learn the secret codes used to store that information. This is the promise of modern artificial intelligence, specifically systems built on large language models. These models act as intelligent assistants, capable of holding a conversation and reasoning through problems. To make them truly useful for businesses, developers connect them to databases—digital warehouses containing everything from customer records to inventory lists. A new standard called the Model Context Protocol has emerged to help these AI assistants find and use external tools, much like a universal remote control that lets a device talk to different brands of appliances. The central challenge, however, is how to design the connection between the human-like AI and the rigid, structured database. If the connection is too loose, the AI might get confused or make dangerous mistakes; if it is too rigid, it cannot answer the unique questions people actually ask.
Researchers recently explored this exact problem by testing how best to build these connections for business data. They compared two very different approaches. The first, and most common, method is to give the AI a single, powerful tool that lets it write its own computer queries from scratch. It is like handing a guest a blank sheet of paper and a pen and asking them to write a letter to a bank, expecting them to know the bank's specific forms, the correct grammar, and the exact rules for calculating interest. The second approach, which the researchers call the "Domain-Oriented Tooling Pattern," is to give the AI a small set of pre-written, specific buttons to press. Instead of writing a letter, the guest simply selects a button labeled "Check Account Balance" or "View Recent Transactions." The complex rules and calculations are already built into the button, hidden safely inside the system.
To see which method works better, the team built a testing ground using a sample movie rental database, a realistic environment with thousands of records about films, customers, and rentals. They set up three different ways for the AI to interact with this data. The first setup allowed the AI to write its own queries from scratch, relying on its own knowledge of the database structure. The second setup gave the AI a set of specialized tools, each designed for a specific business task, such as checking if a customer has overdue movies or finding a film that is currently in stock. The third setup offered a middle ground: a set of tools that were too simple, forcing the AI to still do most of the heavy lifting of figuring out how to combine information. They then tested these setups using four different AI models, ranging from very small and fast ones to larger, more powerful ones, asking them to solve seventeen different real-world business questions.
The results were clear and surprising. The approach that gave the AI specialized, pre-built tools performed significantly better than the one that let the AI write its own queries. When using the specialized tools, the AI answered correctly nearly ninety-four percent of the time. In contrast, when forced to write its own queries, the success rate dropped to about sixty-seven percent. Even more striking was the performance of the simplest AI models. The smallest model tested, which struggled to answer correctly when writing its own queries, achieved a success rate of over ninety-two percent when using the specialized tools. This finding suggests that by simplifying the job the AI has to do—turning a complex writing task into a simple selection task—developers can use much smaller, cheaper, and faster computers to get reliable results. It is as if a small, efficient engine can drive a car just as well as a massive one, provided the car is built with a steering wheel that is easy to turn, rather than one that requires the driver to build the road ahead of them.
The study also revealed that simply giving the AI tools is not enough; the design of those tools matters immensely. A set of tools that was poorly designed, offering only basic access to data tables without clear instructions, actually performed worse than letting the AI write its own queries. This happened because the poorly designed tools removed the AI's freedom to fix its own mistakes without giving it the right information to succeed. The successful tools were carefully crafted to hide the complex business rules inside the system. For example, determining whether a rental is "overdue" involves checking dates and calculating time differences, a rule that the AI often got wrong when writing its own code. With the specialized tools, this rule was already written and tested by humans, so the AI only had to report the result. This shift means that the intelligence required to run the system moves from the AI model itself to the human engineers who design the tools.
The researchers measured not just accuracy, but also the cost and speed of the process. Because the specialized tools required the AI to do less thinking, the system used far fewer computer resources to get the right answer. In some cases, the cost of getting a correct answer dropped by more than ten times when using the specialized tools compared to the raw query method. The system was also faster, taking only a few seconds to respond instead of nearly a minute. This efficiency means that businesses could potentially run these intelligent assistants on their own local computers rather than paying for expensive cloud services, making the technology more accessible and secure. The study concludes that for routine business questions, the best path forward is not to make the AI smarter, but to make the interface it uses simpler and more structured. By organizing data access around clear, human-friendly tasks rather than raw database commands, we can build systems that are more accurate, faster, and capable of running on smaller, more affordable hardware.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.