Labsco
MCP SERVER

Three tools over PostgreSQL, with SELECT-only enforced by parsing the SQL and PII masked before the model ever sees it.

Relational SQL Databases
Summary
Masking that the generated SQL cannot get around.

Plenty of database servers promise read-only and enforce it with a prompt or a keyword check; validating against the parsed statement is a materially stronger claim. The column masking is the part worth adopting even if you already have a Postgres server: rules live in a YAML policy, apply to query results and sample rows both, and are applied server-side, so no clever SELECT recovers the raw value. Start with `--dry-run`, then narrow `SCHEMAS` before pointing anything at a production database.

What it is

A single Go binary that gives a model read access to a PostgreSQL database. The tool surface is deliberately small — map the database, analyse a table, run a query — and the safety model is enforced server-side: read-only transactions, statements validated by parsing rather than string matching, row caps, query timeouts and schema filtering.

What you get
  • `discover` returns the whole landscape in one call — schemas with their tables, sizes, row counts and columns
  • `describe_table` gives a full analysis of one table: columns, types, keys, statistics, sample rows and index usage
  • `query` runs a read-only statement, optionally returning an EXPLAIN plan instead of, or alongside, the rows
  • Only SELECT and EXPLAIN are allowed, and that is checked by parsing the statement's syntax tree rather than matching text
  • Column masking defined in a policy file — mark a column as redacted, hashed, partially hidden or nulled and it is masked in query results and in `describe_table` sample rows alike, with no way for generated SQL to route around it
  • A policy engine that adds business context to what tables and columns actually mean
  • Operational extras — an NDJSON audit log of queries, OpenTelemetry tracing and metrics, and an HTTP transport with bearer-token auth for clients that cannot spawn a binary
Requirements

A PostgreSQL database, version 12 or newer, reachable from the machine. Install the prebuilt binary with the vendor's install script, or `go install` with Go 1.25+, or build from source; a Docker image exists but is aimed at testing since most clients expect a local binary. `DATABASE_URL` is the only required setting. The defaults worth knowing are `MAX_ROWS` at 100 and `QUERY_TIMEOUT` at 10s, with `SCHEMAS` limiting what is exposed and `POLICY_FILE` pointing at the masking and context rules. `--dry-run` validates the config and pings the database, which is the fastest way to confirm the wiring.

Setup effort

One command plus a key — curl -fsSL https://isthmus.dev/install.sh | sh, then supply credentials