CoreBase

Use case · MSSQL

Natural-language queries for Microsoft SQL Server — including legacy versions

CoreBase connects a Model Context Protocol agent to your SQL Server so engineers, analysts, and ops staff can ask questions in plain English. Works on SQL Server 2000 and up. Read-only by default. Raw rows stay inside your network.

View CoreMCP on GitHub

The problem

A decade of operational data lives in your SQL Server: orders, invoices, audit trails, customer history. Every report request becomes a ticket: someone with T-SQL skills writes a query, waits, and hands a CSV back. The data is there but the path to it is slow. And the older the server (2000, 2005, 2008 are still everywhere) the harder it is for modern AI tools — most break onsysobjectsvs.sys.tablesalone.

How CoreBase handles it

CoreMCP — a single Go binary you run on a machine that can reach your SQL Server — exposes the database to CoreBase Cloud (or Claude Desktop, or any MCP client) over Model Context Protocol. You configure a source in YAML and the agent does the rest: schema discovery, query execution, version-aware SQL rewrites.

coremcp.yaml

server:
  name: "coremcp-agent"
  transport: "stdio"

sources:
  - name: "erp_prod"
    type: "mssql"
    dsn: "sqlserver://core_ro:***@10.0.0.5:1433?database=ERP&encrypt=disable"
    readonly: true
    no_lock: true            # WITH (NOLOCK) equivalent — busy OLTP friendly
    normalize_turkish: true  # for Turkish_CI_AS legacy databases
  • Version auto-detection
    On first connect CoreMCP probes @@VERSION and adapts: sysobjects/sysforeignkeys on 2000, OFFSET FETCH→SELECT TOP rewrites on 2008-, LIMIT→TOP everywhere. Same prompts work on a 2003 Sybase-era ERP and a 2022 Azure SQL.
  • Read-only by default
    readonly: true is the source default. INSERT/UPDATE/DELETE never reach the database. Combine with a SELECT-only login for defense in depth.
  • NOLOCK / READ UNCOMMITTED
    no_lock: true runs all reads at READ UNCOMMITTED. Zero shared locks against your transactional workload. Trade-off: dirty reads acceptable for AI / reporting.
  • Turkish_CI_AS collation aware
    normalize_turkish: true folds İ/i/I/ı variants so 'müşteri' matches MUSTERI, MÜŞTERİ, musteri. Critical for Turkish-language legacy ERPs.
  • Custom MCP tools
    Define reusable SQL queries as MCP tools in the same YAML — e.g. top_customers, monthly_revenue. The LLM calls them by name instead of re-deriving SQL each time.

What it looks like

In the panel, the chat or widget, or via the Developer API — same backend, same data, same access policies.

Example prompt

“Top 10 customers by revenue this quarter, grouped by region.”

Generated query

SELECT TOP 10
  c.name,
  c.region,
  SUM(o.total) AS revenue
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE o.created_at >= DATEADD(quarter, -1, GETDATE())
GROUP BY c.name, c.region
ORDER BY revenue DESC

Executed on your server. Returned as a chart + table inline in the chat — raw rows never leave your network.

Why this approach

vs. a cloud BI tool
BI tools need data uploaded or replicated. CoreBase queries in place. No ETL, no data warehouse to fund, no copy of production sitting in someone else's bucket.
vs. generic LLM + raw SQL
GPT/Claude with a SQL Server connector breaks on legacy versions, misses Turkish collation handling, and you have to manage the connection yourself. CoreBase ships the agent, the protocol, the policy layer.
vs. building it in-house
MCP servers, schema introspection, query sanitization, audit logs, RBAC — a 6-month project. CoreBase is one binary plus a config file.

Related

Frequently asked

Which versions of SQL Server are supported?

Every version from SQL Server 2000 through current. CoreMCP auto-detects the server version on connect: it uses sysobjects/sysforeignkeys on 2000, rewrites OFFSET FETCH to SELECT TOP on 2008-and-older, and rewrites LIMIT to TOP for T-SQL compatibility.

Does the AI ever modify our data?

No. CoreMCP's MSSQL source defaults to readonly: true — only SELECT and metadata statements are executed. Use a database login with SELECT-only grants for defense in depth.

How do you handle locking on busy OLTP databases?

Set no_lock: true on the source. All reads then run under READ UNCOMMITTED isolation (equivalent to WITH (NOLOCK)) — zero shared locks, no contention with transactional workloads. Trade-off is potential dirty reads, which is fine for AI/reporting queries.

Does it work with Turkish_CI_AS collation databases?

Yes. CoreMCP normalizes Turkish character variants (İ/i/I and ı) so prompts like 'müşteri bilgileri' match column names regardless of the user's locale. Common gotcha on legacy Turkish ERP databases.

Where do the query results go?

Rows execute on your server inside CoreMCP and flow back over a TLS-encrypted MCP connection to CoreBase Cloud for the LLM call. Sensitive workloads can run the entire stack air-gapped via the Enterprise Container — raw rows never leave your perimeter at all.

See it against your own SQL Server

Book a demo and we'll connect CoreBase to a database that looks like yours — legacy version, Turkish collation, busy OLTP, behind your firewall.

View CoreMCP on GitHub