sql-steward
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SQL_STEWARD_MASK | No | Optional: set to '1' to enable PII masking on results. | |
| SQL_STEWARD_ROLE | No | Optional: role name for query-warden access control. | |
| SQL_STEWARD_LAYER | Yes | Path to the semantic layer YAML file defining entities, metrics, and policies. | |
| SQL_STEWARD_DB_URL | Yes | SQLAlchemy database URL (e.g., postgresql+psycopg://user@host/db). | |
| SQL_STEWARD_POLICY | No | Optional: path to a second-pass role policy YAML file. | |
| SQL_STEWARD_AUDIT_DB | No | Optional: path to SQLite database for agent-blackbox audit chain. | |
| SQL_STEWARD_EMBED_URL | No | Optional: URL for local embedding endpoint (e.g., http://localhost:11434/api/embeddings). | |
| SQL_STEWARD_EMBED_MODEL | No | Optional: model name for embeddings (e.g., nomic-embed-text). | |
| SQL_STEWARD_QUERY_BUDGET | No | Optional: hard cap on queries per role per session (integer). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_entities | List the entities (tables) you may read, plus the available metrics. Call this first. You never write SQL -- you pass names from here to get_records / get_metric and sql-steward compiles the query for you. |
| describe_entity | Show one entity's fields, types and PII tags. Fields tagged with a blocked PII category are marked |
| list_metrics | List pre-approved metrics and the dimensions/filters each one allows. |
| get_records | Read rows from one entity.
|
| get_metricA | Compute a pre-approved metric, optionally grouped/filtered by allowed dimensions. The aggregation itself is fixed by the semantic layer. |
| semantic_search | Vector similarity search over an entity's embedding column (pgvector).
|
| list_checksA | List the declared data-quality checks the layer can run. |
| run_checksA | Run the declared data-quality checks and return a readiness summary. Each check compiles to a read-only violation count; zero violations passes. Returns a readiness score (percent of checks passing), an overall status, and a per-check breakdown. An 'error'-severity failure makes the status 'failing'; a 'warn'-severity failure makes it 'degraded'. |
| audit_verifyA | Verify the tamper-evident audit chain (agent-blackbox), if enabled. Reports whether any previously recorded call was altered after the fact. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool maps to a distinct task: listing checks, executing checks, verifying audit integrity, and computing metrics. No two tools have overlapping purposes, so an agent can select unambiguously.
list_checks, run_checks, and get_metric follow a clear verb_noun pattern, but audit_verify breaks the pattern by leading with the noun. This is a minor inconsistency rather than a chaotic mix.
Four tools is well-scoped for a focused SQL stewardship server: each tool covers a necessary function without redundancy or bloat.
The read-only governance surface is well covered: checks can be listed and run, audit integrity can be verified, and approved metrics can be computed. Minor gaps exist for those expecting per-check execution or metric catalog details, but the core workflows have no dead ends.