PaperlayerView exact revision on arXiv

Source-linked AI summary

From SQL Generation to Tool Selection: A Domain-Oriented Pattern for MCP Servers

Bartolomeo Bogliolo

arXiv:2608.22063v1cs.AIcs.DB

TL;DR

Generic SQL tools leave schema navigation, joins, business-rule interpretation, and validation to open-ended model synthesis. The paper replaces that process with domain-oriented tool selection backed by server-side parameterized SQL, and reports that a verticalized pack outperforms raw SQL and a generic pack while enabling smaller models.

  • Problem

    Generic SQL interfaces require models to repeatedly navigate schemas, infer joins and business rules, generate dialect-correct queries, and validate results for each request.

  • Method

    The paper proposes domain-oriented tooling, where models select a small set of domain-aligned operations backed by parameterized SQL, formalizes the pattern, and implements it in MCP Blueprint.

  • Results

    0.939 pooled mean score for the verticalized pack versus 0.666 for raw SQL and 0.605 for the generic thin-tool pack.

  • Takeaways & Limitations

    Replacing SQL synthesis with intent classification bounds failure modes, supports smaller or less expensive models, and keeps semantic content on the server for more deterministic behavior.

  • Takeaways & Limitations

    Generic interfaces leave business rules implicit in schema conventions, requiring their interpretation to be re-derived on each invocation and allowing variation across runs, models, and prompts.

Abstract

from arXiv · show

Agents built on Large Language Models (LLMs) increasingly reach enterprise data through the Model Context Protocol (MCP), and many MCP database servers maximize flexibility by exposing a single generic SQL execution tool. This paper proposes the Domain-Oriented Tooling Pattern: instead of generating SQL at query time, the model selects from a small set of domain-aligned tools whose parameterized queries encapsulate schema navigation, joins and business rules on the server side. We formalize the pattern around three architectural invariants and introduce Model Demotion, the observation that replacing SQL synthesis with intent classification lowers the model tier required to serve routine requests. As a reference implementation we present MCP Blueprint, an open-source framework in which domain tools are defined declaratively as YAML metadata plus external parameterized SQL files. We evaluate the pattern with a public reproducibility benchmark comparing three MCP server designs - raw SQL execution, a thin generic tool pack, and a verticalized domain pack - on four local models (3B-8B) across seventeen customer-facing tasks over the Sakila database (609 completed cells; temperature 0; three repetitions per cell). The verticalized pack reaches a pooled mean score of 0.939 versus 0.666 for raw SQL and 0.605 for the generic pack; the smallest model improves from 0.583 to 0.929, matching or exceeding every larger configuration while cutting cost per correct answer by an order of magnitude. All harness code, prompts, gold answers, frozen packs and per-cell results are publicly available.

Introduction

The paper argues that MCP database servers should expose domain-aligned operations rather than generic SQL, shifting schema and business-rule handling from models to the server. Its benchmark reports substantially stronger accuracy and lower model requirements for verticalized tooling.

  • Problem: Generic SQL tools maximize flexibility but transfer schema discovery, relationship inference, dialect handling, business-rule interpretation, optimization, and validation to the model.These responsibilities introduce non-determinism and can widen the security surface.
  • Proposed pattern: The Domain-Oriented Tooling Pattern replaces SQL generation with selection among domain-aligned operations backed by parameterized SQL that encapsulates joins and business rules.The server exposes business concepts instead of database implementation details.
  • Contributions: The paper formalizes three architectural invariants, introduces Model Demotion, presents MCP Blueprint, and releases a reproducibility benchmark spanning four local models and seventeen enterprise-style tasks.Model Demotion frames interface simplification as lowering the model tier needed for routine requests.
  • Results: 0.939 pooled accuracy for the verticalized pack exceeded 0.666 for raw SQL and 0.605 for the generic thin-tool pack.The result is reported across the benchmark’s measured configurations.
  • Results: The smallest 3B model matched every larger configuration, while cost per correct answer fell by roughly 2–12×.The generic pack underperformed even raw SQL, indicating that tool design rather than tool existence created value.

Background and Motivation

Generic database interfaces expose implementation-level query work to probabilistic models, creating recurring context, execution, semantic, and security burdens. The paper frames these limitations as production-serving concerns rather than a verdict on text-to-SQL research.

  • MCP background: MCP standardizes typed tool discovery and invocation, while database connectors commonly expose one generic query tool with schema DDL supplied to the model.The representative interface is an arbitrary execute_sql operation taking a query string.
  • Generic query interfaces: Raw SQL answering requires discovering relevant tables, inferring joins, interpreting business semantics, generating dialect-correct SQL, and validating returned rows.These are implementation concerns rather than the user’s business question.
  • Operational limitations: Enterprise schemas with hundreds of tables and thousands of columns consume context across agent iterations, increasing cost and latency while diluting attention on the task.Schema metadata must be ingested before correct SQL can be formulated.
  • Operational limitations: Generated queries may be inefficient or unsafe, including unindexed scans, Cartesian products, excessive data retrieval, connection-pool starvation, and lock contention.These risks arise because queries are synthesized anew for each run.
  • Operational limitations: Models must re-derive implicit business rules on every invocation, producing interpretations that vary across runs, models, and prompt phrasings.Examples include active-account and overdue-rental states defined through multi-column and temporal conditions.
  • Operational limitations: Generic execution tools broaden read capability and expose systems to indirect prompt injection, bulk harvesting, and resource-exhaustion patterns.The paper distinguishes these deployment limitations from the continued progress of text-to-SQL research.

The Domain-Oriented Tooling Pattern

The Domain-Oriented Tooling Pattern treats the MCP server as a domain gateway: models select bounded semantic operations while the server encapsulates data-access decisions, joins, and business rules.

  • Core philosophy: “Do not expose the database. Expose the domain.” summarizes the pattern’s central abstraction choice.The directive shifts the interface from storage primitives toward business concepts.
  • Core philosophy: The LLM acts as an orchestrator requesting semantic information or domain actions, while every data-access decision remains encapsulated inside the server.The server sits between intent and relational SQL.
  • Architectural comparison: Domain-oriented tools use named operations and stable documented outputs instead of arbitrary SQL, per-request schema discovery, generated joins, and model-derived business rules.Joins are pre-authored and optimized, and business rules are embedded in server-side SQL.
  • Relation to prior abstractions: The pattern extends abstraction precedents from object-relational mapping, REST resources, and domain-driven design to probabilistic clients.Tools correspond to bounded-context operations rather than storage primitives.

MCP Blueprint: A Reference Implementation

MCP Blueprint implements domain-oriented tooling through declarative packs that separate shared protocol infrastructure from versionable, reviewable domain artifacts.

  • Framework architecture: MCP Blueprint replaces bespoke imperative server code with declarative configuration files called packs.The framework enforces a separation between engine and domain-pack concerns.
  • Framework architecture: The engine layer handles transports, pooling, validation, caching, and errors across database engines, while packs contain YAML definitions, parameterized SQL, and metadata.This separation keeps protocol infrastructure domain-agnostic.
  • Pack structure: The Sakila pack organizes compatibility metadata, declarative tool definitions, and external parameterized SQL files under a pack directory.The structure separates pack declaration, tools, and SQL artifacts.
  • Authoring workflow: Adding a domain operation requires one YAML definition and one reviewed SQL file, making it a configuration change rather than a code change.The example handles an availability rule and an optional parameter directly in SQL.

Model Demotion

Model Demotion reframes routine database requests as intent classification and slot filling rather than open-ended SQL synthesis, allowing domain-oriented tools to lower the model tier required. The pattern targets bounded recurring workflows, while exceptional requests remain subject to human-authored coverage expansion.

  • Model Demotion lowers the model tier required for routine requests by reducing interface complexity.
  • Domain-oriented interfaces replace schema navigation and SQL generation with selecting an operation and extracting typed parameters.
  • Intent classification over a small tool set can run on small local models or inexpensive API tiers, while bounded selection failures are easier to detect and repair.
  • At temperature 0, fixed tools move semantic content from model weights into the server, promoting behavioral convergence across models.
  • The heuristic applies to bounded, recurring retrieval workflows rather than open-ended analytical exploration.
  • Exceptional requests enter a human-in-the-loop process in which domain engineers author new YAML/SQL definitions that expand deterministic coverage.

A Public Reproducibility Benchmark

The benchmark compares raw SQL, a thin generic pack, and a verticalized domain pack across four local models and seventeen Sakila tasks. The verticalized design leads in accuracy, efficiency, and consistency, while exposing tools without domain-oriented design can underperform raw SQL.

  • Approaches: Approach B uses five domain tools with human-readable identifiers and pre-authored SQL encapsulating joins and business rules.Approach A exposes one execute_sql tool, while C uses shallow table-oriented tools with minimal descriptions.
  • Benchmark Design: 609 completed cells evaluate three MCP server designs across four local models, seventeen customer-facing tasks, and three repetitions per cell.The protocol used temperature 0, seed 42, an 8192-token context window, and at most 10 agent steps.
  • Accuracy Results: 0.583 → 0.929 is the smallest model’s improvement from raw SQL to domain tools, with llama3.2:3b increasing from 6/51 to 42/51 fully-correct cells.Approach B never drops below 0.90 on any model, while the generic pack pools below raw SQL and trails it on three of four models.
  • Efficiency: 4.4 s mean latency for B compares with 6.4 s for C and 17.3 s for A, making B both the most accurate and fastest design.Mean agent steps were 2.1, 2.4, and 2.4, while mean tool calls were 1.1, 1.7, and 1.6 for B, C, and A respectively.
  • Efficiency: 2,723 tokens per correct answer replaces 31,476 for llama3.2:3b when moving from raw SQL to the verticalized pack.The same model used 2,242 tokens and 2.8 seconds per cell with B, versus 3,703 tokens and 5.8 seconds with A.
  • Per-Task Analysis: 15 of 17 tasks are fully solved by at least three of four models under B, including twelve tasks solved by all four.Simple one-query tasks converge at 1.000 across approaches, whereas recommendation, negative-filtering, and workflow tasks show gaps of +41.6pp to +50.0pp.
  • Threats to Validity: Task-aligned scoring, one small Sakila schema, local 3B–8B models, fixed temperature, and hardware-relative latency limit generalization beyond this benchmark.No held-out task set was evaluated; three cells were lost and two models lacking tool-calling support were excluded.

Discussion

The discussion positions verticalized tools as a production-oriented abstraction for recurring operational questions, while retaining generic SQL for exploratory analytics. It also connects declarative packs to reviewable governance and a narrower database security boundary.

  • For Practitioners: The suggested deployment sequence inventories recurring questions, exposes named domain operations, and pushes joins and business rules into reviewed SQL.Tool definitions are treated as versioned API contracts covered by tests, with an escape hatch for uncovered requests.
  • Relation to Text-to-SQL: NL-to-SQL remains appropriate for exploration, ad-hoc analytics, and prototyping, while bounded operations suit production serving paths with server-side semantics.A pragmatic deployment can offer both surfaces to different audiences under different credentials.
  • When Generic Interfaces Suffice: Generic SQL tools remain reasonable for expert analysts working with exploratory data and low-consequence tasks.The pattern instead targets recurring operational questions, non-expert users, and autonomous agents without human review of each query.
  • Ecosystem Implications: Declarative packs support code review, database portability, role-based visibility filtering, and registries of tested domain packs.Removing arbitrary-query access means indirect injection can manipulate routing but cannot rewrite the queries themselves.

Related Work

The paper places domain-oriented tooling within research on agentic tool use, text-to-SQL, data-access abstractions, small models, and MCP reliability. Its distinction is to treat tool-surface design as a first-order benchmark variable rather than a fixed interface.

  • Agentic Tool Use: Prior agentic-tool research studies interleaved reasoning, self-supervised tool calls, large API tool selection, and function-calling accuracy.This paper differs by benchmarking how the design of the available tool surface affects outcomes.
  • Text-to-SQL: Text-to-SQL systems optimize SQL generation through cross-domain benchmarks, decomposition, and prompt engineering, whereas this pattern removes generation from the serving path.The paper presents the two approaches as complementary rather than competing.
  • Abstraction Layers: ORMs, REST resources, semantic layers, and domain-driven design provide precedents for bounded, governed data-access abstractions.The pattern adapts this lineage to probabilistic clients whose descriptions and parameter contracts must steer natural-language routing.
  • Small Open Models: Research on Llama 3, Qwen2.5, Phi-3, and Gemma 2 established runnable 3B–8B models, but typically evaluates generation-heavy tasks.This benchmark instead measures how interface design shifts the model tier needed for reliable tool use.
  • MCP Reliability: Related MCP reliability work addresses interoperability, agentic-system economics, and prompt-injection defenses, while this contribution hardens the agent–database boundary.The paper therefore claims an orthogonal contribution to the ecosystem literature.

Conclusion and Future Work

The paper concludes that curated domain operations can replace generic SQL execution for routine agent requests and enable smaller models to serve them reliably. Its benchmark supports this claim while motivating broader replication, model, authoring, and governance studies.

  • Conclusion: The Domain-Oriented Tooling Pattern rests on encapsulated data access, deterministic business rules, and declarative tool definition.MCP Blueprint separates protocol infrastructure from domain knowledge through declarative implementation.
  • Conclusion: 0.939 pooled mean score for the verticalized pack exceeds 0.666 for raw SQL and 0.605 for the generic thin-tool pack.Every model gained, with the smallest improving from 0.583 to 0.929; cost per correct answer fell by roughly 2–12×.
  • Conclusion: Tool design, rather than tool existence or model scale, is identified as the decisive factor in the benchmark.The artifacts, including harness code, prompts, gold answers, frozen packs, and per-cell results, are public.
  • Future Work: Five future-work lines propose cross-domain replication, frontier-model and temperature studies, automated pack authoring, governance features, and further evaluation.The listed agenda includes held-out task protocols separating pack authoring from evaluation.

Declarative Tool Specification

The paper specifies domain tools as paired YAML and SQL artifacts that encode routing, parameters, queries, and business rules declaratively. This separation supports review, testing, versioning, portability, bound parameters, and reusable optional filtering.

  • Tool structure: A complete domain tool pairs one YAML file with one SQL file defining metadata, typed parameters, backing SQL, and cache behavior.The YAML description serves as the model’s primary routing signal.
  • Tool structure: The film-stock tool returns per-store copies, availability, rating, and length while supporting case-insensitive title matching and optional store filtering.Its parameter declarations distinguish the required title from the optional store_id filter.
  • Query behavior: Bound placeholders prevent injection, while the SQL computes availability from whether an open rental references each inventory copy.The model supplies values, but the query retains the business rule.
  • Query behavior: A template conditional removes the store filter when store_id is omitted, allowing one definition to serve filtered and unfiltered calls.When supplied, store_id constrains results to one store.
  • Operational benefits: The declarative YAML and SQL artifacts can be reviewed, tested, versioned, and ported to another database engine without changing protocol code.The SQL remains isolated from application code.

Benchmark Tasks

The benchmark defines seventeen customer-facing tasks spanning customer lookup, rental histories, standing and overdue checks, recommendations, stock questions, service cases, empty histories, and unrented films.

  • Customer and rental tasks: 17 customer-facing tasks cover customer identification, rental history, outstanding rentals, and account-status checks.Examples include finding a customer, reviewing Mary Smith’s rentals, and checking overdue rentals.
  • Recommendation tasks: Recommendation tasks request films by customer standing, category, rating, or current availability.The task set includes Sci-Fi, Family, G-rated, and in-stock recommendations.
  • Catalog and inventory tasks: Stock and film-information tasks ask about available copies and store-specific inventory for a named film.One task asks whether Goodfellas is in stock at Store 2.
  • Service and edge cases: Service and edge-case tasks combine late-fee investigation with currently loaned and overdue films, home-store information, empty rental history, and films not previously rented.These tasks test multi-step account reasoning and non-match handling.
Loading 2608.22063v1…