Safe DB Gateway
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DB_HOST | Yes | PostgreSQL host for the gateway database. | |
| DB_NAME | Yes | Name of the PostgreSQL database to connect to. | |
| DB_PORT | Yes | PostgreSQL port for the gateway database. | |
| DB_SEED | No | Controls database seeding; use 'empty' to skip demo data and connect to an existing database. | |
| GATEWAY_ROLE | Yes | Keycard role that determines access level (reader, editor, or admin). |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_gateway_healthA | Returns the real-time health, anomaly circuit breaker state, and quota usage of the database gateway. |
| safe_queryA | Safely executes a read-only SQL query against the database. Guarantees:
|
| list_accessible_tablesA | Lists the tables the agent is permitted to query, along with descriptions. Prevents the LLM from hallucinating queries against internal/restricted tables. |
| describe_tableB | Returns column names, data types, and primary key constraints for an accessible table. |
| sample_rowsA | Returns up to 3 representative rows from an accessible table. Lets the agent see real data shapes before writing queries. Same read pipeline as safe_query: throttle gate, whitelist, role read-scope, AST validation, PII masking, audit. |
| propose_mutationA | Human-in-the-Loop (HITL) Proposal Tool: Submits a proposed data mutation (INSERT, UPDATE, DELETE) for review. Does NOT execute the mutation. Generates a proposal token and dry-run query plan. |
| apply_mutationA | Authenticated Human-in-the-Loop (HITL) Execution Tool: Executes a previously vetted mutation proposal IF AND ONLY IF a valid operator approval key is provided. The LLM cannot self-approve; a human administrator must provide the secret key. |
| get_audit_summaryA | Read-only audit summary: returns the last N gateway audit events. Lets the operator ask 'what happened in the last 10 minutes' without opening files manually. |
| reset_quarantineA | Management tool (admin role only): clears the session quarantine. Lets the owner recover the gateway without restarting the process. Never gated by the circuit breaker itself. |
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 9 tools
Each tool maps to a clearly distinct responsibility: health, read querying, schema/metadata inspection, sampling, mutation proposal, mutation execution, audit, and quarantine recovery. The phase separation between propose_mutation and apply_mutation is especially unambiguous.
Most tools follow a verb_noun snake_case pattern (get_, list_, describe_, sample_, propose_, apply_, reset_). safe_query is the one exception because it is an adjective-noun phrase rather than a verb-first action, but it is still clear and consistent in style.
Nine tools is well-scoped for a database gateway. Each tool covers a distinct part of the workflow without redundancy, and no tool feels like filler.
The set covers the full intended lifecycle: read-only querying, table discovery, schema inspection, data sampling, HITL mutation proposal and approval-gated execution, health monitoring, audit, and quarantine recovery. Minor optional additions like proposal listing are not necessary for the core workflow.