Don't expose the database.
Expose the domain.

Your agent is writing SQL. It should be selecting tools.

Exposing a generic execute_sql tool forces the model to discover schemas, infer joins, re-derive business rules, and handle dialect differences on every request. That consumes reasoning capacity, introduces non-determinism, and pushes teams toward expensive frontier models just to compensate for an interface that exposes implementation details instead of business concepts.

Up and running in two minutes

pip install mcp-blueprint            # Core: PostgreSQL, MySQL, MariaDB, SQLite
pip install mcp-blueprint oracle     # + Oracle
pip install mcp-blueprint clickhouse # + ClickHouse
pip install mcp-blueprint sqlserver  # + SQL Server
pip install mcp-blueprint duckdb     # + DuckDB (embedded, no server)
pip install mcp-blueprint databases  # + Oracle + ClickHouse + SQL Server

{
  "mcpServers": {
    "pg-dba": {
      "command": "mcp-blueprint",
      "args": ["--config", "config/pg-dba.toml"]
    }
  }
}

# tools/film_stock.yaml
name: film_stock
description: Per-store stock for a film found by title.
parameters:
  title:
    type: string
    required: true
sql: ../sql/film_stock.sql

-- sql/film_stock.sql
SELECT f.title, s.store_id,
       COUNT(i.inventory_id) AS total_copies
FROM film f
JOIN inventory i ON i.film_id = f.film_id
JOIN store s ON s.store_id = i.store_id
WHERE f.title ILIKE '%%' || %(title)s || '%%'
GROUP BY f.title, s.store_id;

How it works

The LLM never writes SQL — it selects from a curated set of domain tools. Every join, filter, and business rule lives server-side in reviewed SQL files.

• The agent classifies user intent and selects a domain tool — no SQL generation involved.
• MCP Blueprint validates parameters, renders the SQL template, and manages connection pooling.
• Pre-authored SQL executes with bound placeholders (injection-safe) and returns stable, documented columns.
• The model reports the result instead of reconstructing it. Equivalent quality at a fraction of the inference cost.

One YAML + one SQL per tool

Packs are self-contained artifacts: YAML tool definitions, parameterized SQL files, and pack metadata. Add a domain operation as a configuration change, not a code change. Clone an existing pack and adapt it to your schema, or create one from scratch — the engine handles transports, pooling, and validation.

Start from the Sakila example pack and adapt it to your domain — or create a new pack from scratch. One YAML + one SQL per tool, no Python code required.

Built for production, not just prototypes

MCP Blueprint ships with the infrastructure that production deployments require: security by default, full audit trails, observability, and multi-engine support.

Model Demotion: small models beat raw SQL

A public reproducibility benchmark compares three server designs across four local models (3B–8B) and seventeen enterprise-style tasks. The verticalized pack dominates every measured dimension. The smallest 3B model gains the most — the empirical signature of Model Demotion.

Tool design, not tool existence, creates value. A generic pack scores below raw SQL (0.605 vs 0.666). Full benchmark: mcp-blueprint-benchmark.

The paper behind the framework

A peer-reviewed arXiv publication formalizes the Domain-Oriented Tooling Pattern and reports the full benchmark methodology, results, and analysis.