LabscoMCP early access ↗
corebasehqMCP SERVER

CoreMCP

Put SQL Server and PostgreSQL databases in front of an assistant from one static Go binary — read-only by default, behind a SQL lexer that fails closed.

by corebasehq ↗Relational SQL DatabasesCommunity

LABSCO SUMMARY

Two layers between a model and the database, and the project tells you plainly not to trust either one on its own.

The lexer is the part worth reading about: instead of reaching for a general SQL parser, it tokenises, strips comments and literals, and admits only SELECT and WITH, with any stray semicolon fatal so stacked queries die independently of dialect. The forced row cap and the PII masking sit behind it. The documentation is unusually direct that this is defence in depth and the real boundary is a least-privilege database role. The NOLOCK and Turkish-normalisation options make clear which kind of estate it was built against.

What it is

A Go server that exposes configured SQL sources as MCP tools: run a query, list tables, describe one, list views and stored procedures, and — only when writes are enabled — call a procedure. It ships as a single binary with its drivers embedded, speaking stdio or an outbound WebSocket for a database behind NAT.

What you get

  • query_database runs SQL against a named source; list_tables returns tables with column counts, primary keys and foreign key counts; describe_table gives one table's columns, types, nullability, keys and column comments
  • list_views returns views with their column definitions, and list_procedures returns stored procedures with parameter names, types and modes plus a ready-to-copy example call
  • execute_procedure calls a procedure with named parameters bound rather than interpolated, and exists only on a source where readonly has been set to false
  • Custom tools: a parameterised query declared in the configuration becomes a first-class MCP tool with its own parameter schema, so a recurring report is one call rather than SQL re-derived every turn
  • A database_schema prompt built at startup from every source — tables, columns, keys, relationships and column comments such as MS_Description — so the model has schema context without a manual dump in each conversation
  • A T-SQL aware lexer strips comments and string literals, then admits only SELECT and WITH; DROP, ALTER, UPDATE, DELETE, TRUNCATE, EXEC, OPENROWSET and SELECT…INTO are rejected before the database sees them, and any semicolon outside a string or comment is fatal, so stacked queries fail regardless of dialect
  • A forced row cap is appended or wrapped around every SELECT, so a query cannot stream millions of rows back through the protocol
  • Regex-based PII masking over result strings before they leave the server, with the patterns and replacements declared in the configuration
  • Two options aimed at legacy MSSQL estates: no_lock runs SELECTs under READ UNCOMMITTED, and normalize_turkish folds Turkish characters in string literals on the way out and repairs Windows-1254 mojibake on the way back

Requirements

A single static binary for Linux, macOS and Windows from the releases page, a one-line installer, a multi-arch Docker image, or a build from source with Go 1.23 or newer. Configuration is a coremcp.yaml naming each source and its DSN. The MSSQL adapter covers SQL Server 2000 and newer and the PostgreSQL adapter is stable; Firebird is in progress and its factory currently returns a placeholder error, and MySQL is on the roadmap. Sources are read-only unless readonly is set to false, and the project recommends a dedicated database user holding SELECT — and EXECUTE only on the procedures you meant to expose — rather than relying on the server-side guard alone.

Setup effort

One command plus credentials — curl -fsSL https://get.corebasehq.com | sh, then supply credentials

See installation options